1. Technical Field
This invention relates to a system and method for maximizing the efficiency of the load balancing among web servers included in an asymmetric server farm.
2. Description of the Prior Art
One of the basic goals in the creation of the Internet was the ability to share computer resources among users. Accordingly, the Internet has enabled the availability of several different types of computer related services to users. The World Wide Web (WWW) is the most commonly used computer related service. Users, or clients, of computer related services enabled by the Internet, are able to request virtually unlimited amounts of information and receive that information in an easily understandable and useable format. File Transfer Protocol or FTP is another frequently used service enabled by the Internet which assures file access. Email service, which enables users to exchange messages quickly and easily via the Internet, is also very popular.
In the client-server model, web servers are the computer resources which process client applications or requests. A load balancing server enables the flow of traffic to the web servers and acts as a delivery service from the web servers back to the clients. Regular servicing of client requests, i.e., the ability to receive a request from a client by a web server and then provide a response back to the client, is generally described in “Operating Systems: a design-oriented approach”, Charles Crowley, Irwin, 1997, ISBN 0-256-15151-2.
Because web servers are limited by their own computing power, a web server is only able to carry out a limited number of operations in a given unit of time. And, because several operations may be required to properly answer each service request from a client, the web server may be able to process only a finite number of client service requests during any given time period. Thus, it is the computing power of the web server that provides a limit on the number of client service requests that can be responded to during any given unit of time. When the computing power of the web server is insufficient to respond to all client service requests, some client service requests are not met. When possible, the problem of not responding to a client service request is remedied by an upgrade in web server computing power to decrease the number of unserved client service requests.
The approach of continuing to upgrade the computing power of the web server has some disadvantages, since there is a limit to the computing power of web servers which are commercially available. Additionally, the incremental cost to upgrade a web server is not proportional to the increased computing power, i.e., doubling the power of a web server more than doubles its cost.
It has been found that the use of more than one web server to respond to client service requests eliminates the problem of reaching the capacity limit of a single web server, while the cost of using more than one web server remains directly proportional to the computing power obtained. The maximum computing power available to process client service requests will then depend on the number of web servers in use and will not be restricted by the limitations of the individual web server computers presently available in the marketplace.
A group of web servers, linked together for responding to client server requests, is called a web farm. Individual web servers within the web farm are called real servers. For more details about web servers, see R. S. Engelschall “Load balancing your web site: Practical approaches for distributing http traffic,” Web Techniques Magazine, 3 (5), May 1998 and Allon et al., U.S. Pat. No. 5,539,883. According to the way the Internet functions, a request from a client sent to a particular address can only be received by one network web server. When a load balancing server is installed at the web farm receiving client service requests, one or more individual real servers in the web farm can be used to process the requests sent to the web farm. The load balancing server performs the following functions in a web farm:                receives client service requests;        selects one or more real servers to process the client service request;        forwards the client service request to the real server;        
receives the real server response to the client service request; and                forwards the real server response back to the client that initiated the client service request.        
Thus, all of the client service requests to the web farm must first go through the load balancing server. The passage of each client service request through the load balancing server requires some amount of processing time. Therefore, both the web farm and the power of the load balancer limit the ability of the web farm to respond to client request. Thus, the efficiency of the load balancing server is extremely important.
High-level protocols such as HTTP, FTP, and POP3, which establish the rules and parameters that define and enable communication through a network, govern the processing of the messages carrying the client service request and the return of the message carrying the response to the client server request from the web server. Protocol rules require that both the message carrying the client service request and the message carrying the response from the web server be a syntactically correct byte chain. A sample client service request message consists of a resource name, i.e., URL, file name, message number. Prior to sending the resource name, the client may exchange additional messages with the web server, but all of the exchanged messages must conform to the protocol rules, e.g., for user authorization. All of the messages (including the client service request and the response to the client service request), generated between the client and the web server during the connection period, constitute a session. Additional details regarding the use of specified protocols may he found in Network Working Group, “Request for Comments: 2616 Hypertext Transfer Protocol.
Two web farm types may be distinguished: symmetric and asymmetric. A web farm in which all of the real servers are able to process an equal set of client service requests is typically called a symmetric web farm. A web farm in which each real server is specialized to service a specified class of requests is typically called an asymmetric web farm.
In a symmetric web farm, incoming traffic is distributed among replicated servers, thus permitting server clusters to share the processing load, to provide for over capacity situations, and to speed up the response time for users.
In a symmetric web farm, load balancing servers operate to route traffic to the best web server available to handle a client request. Load balancing policies implemented by the load balancing server are defined which reflect the capabilities of the real servers and direct client requests based on the capabilities of the web farm real servers.
For example, in an asymmetric web farm, an HTTP service implies that one asymmetric web farm real server processes html text page requests and another asymmetric web farm real server processes image requests.
In contrast, in a symmetric web farm, all real servers must be able to process both a page request and an image request. Further information regarding symmetric farms 10 may be found in Rege, U.S. Pat. No. 5,612,897.
Functions of the load balancing server for a symmetric web farm and an asymmetric web farm differ. In a symmetric web farm, the load balancing server does not define the resource requested, as all of the real servers have an equal set of resources available. The load balancing server does not wait for the client service request to arrive. Rather, the load balancing server simply selects a random real server. Although relatively simple conceptually, the symmetric web farm is quite challenging to properly support. For an administrator to maintain identical contents in all of the real servers is a highly technical task. In addition, maintaining identical contents in all of the real servers requires extra long-term memory capacity. For the real servers of an asymmetric web farm, it is not essential for all web servers to know how to answer each client service request. Rather, it is essential for the web farm, however, to be able to assure availability of the proper type of real server to process each client service request (for example, all *.gif type URLs are processed at one real server, and all *.html type URLs are processed at another real server). The load balancing server, thus, selects a real server which is capable of processing a particular client service request, and then forwards the client service request to the selected real server. Prior to receiving the client service request, the load balancing server is in continuous communication with the client according to the web server protocol. Upon receiving the client service request, the load balancing server forwards all client service request information to the real server, even if the protocol calls for an additional exchange of information. This means that the load balancing server stores all of the information from the initial session and then later forwards the information to the real server. Selection of the real server according to the type of resource requested is further detailed in Brendel, et al., U.S. Pat. No. 5,774,660 and Brendel, U.S. Pat. No. 6,182,139.
To exchange messages using a high-level protocol, lower level protocols are used. For the Internet, such lower level protocols are represented by TCP protocols that guarantee correct data delivery. The TCP protocol treats high-level protocol messages, such as client service requests and the responses from web servers, as data to be delivered. To deliver data from one web server to another, a TCP connection between the web servers is required. The data to be delivered from one web server to another by a TCP connection is split into data packets, with each data packet being sent separately. At the receiving end of the message, the data packets are appropriately assembled together, such that an addressee receives the data in succession as transmitted by the sender. Each data packet receives an additional header, called a TCP header. The TCP header bears the information necessary for successive assembly of the data packet. The TCP header also carries information on masked data distortions. The information on masked data distortions is referred to as the checksum and is acquired from the TCP header and the data packet contents. When there is data distortion, the checksum at the addressee will not match the checksum which is stated in the TCP header and validation of a properly transmitted message cannot occur. TCP header fields, or options, optimize the speed of data transmission. The set of TCP header fields is defined upon connection and depends on the type of TCP protocol used.
The TCP protocol also uses a lower level IP protocol. The scheme under which one higher level protocol uses another lower level protocol is referred to as a stack. For instance, TCP/IP and other (e.g., ICMP, ARP, etc.) protocols constitute a TCP stack. TCP stacks are further described in Network Working Group “Request for Comments: 1180 A TCP/IP Tutorial.”
The attachment or implementation of a TCP stack on a message typically occurs in that part of the operating system resident in the kernel space of a computer resource. Applications capable of receiving messages with high-level protocols (e.g., HTTP, FTP, POP3) are typically resident within the user space and use the TCP stack functions by means of special system calls. Accordingly, the TCP connection as well as the reading and transmission of data is provided by the system calls. Service of a particular protocol located in user space is only able to access data. Within user space, operations such as splitting data into packets, calculation of checksums, and packet headers, remain inaccessible since they occur inside the TCP stack. More details about system calls may be found in “Operating System Concepts” by Abraham Silberschatz, Peter Galvin, John Wiley & Sons, ISBN: 0471364142.
The concept of the Linux Virtual Server (LVS), described in Wensong Zhang “Linux Virtual Server for Scalable Network Services”, Ottawa Linux Symposium 2000, represents the closest analogue to the Server Load Balancing System of the present invention. Specifically, the Linux Virtual Server and the disclosed Server Load Balancing System share the following features:                service is a part of the operating system resident in the kernel space; and        a client request is treated as a succession of data packets.        
The major difference between the disclosed server load balancing system and the Linux Virtual Server is that the Linux Virtual Server is not able to work with an asymmetric web farm. The Linux Virtual Server provides no internal buffer until the request-processing server has been chosen. Thus, web servers connected to a Linux Virtual Server are unable to balance their loading by the contents of client requests. Additionally, the Linux Virtual Server does not use a TCP stack, but rather uses lower level functions to send and receive data packets.
A need remains in the art, therefore, for a system and method to maximize the load balancing service for real servers in an asymmetric web farm.